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Abstract 

The work described in this paper was motivated by our 
experience with applying a framework for formal anal- 
ysis of human-machine interactions (HMI) to a realistic 
model of an autopilot. The framework is built around 
a formally defined conformance relation called “full- 
control” between an actual system and the mental model 
according to which the system is operated. Systems are 
well-designed if they can be described by relatively sim- 
ple, full-control, mental models for their human oper- 
ators. For this reason, our framework supports auto- 
mated generation of minimal full-control mental mod- 
els for HMI systems, where both the system and the 
mental models are described as labelled transition sys- 
tems (LTS). The autopilot that we analysed has been 
developed in the NASA Ames HMI prototyping tool 
ADEPT. In this paper, we describe how we extended 
the models that our HMI analysis framework handles 
to allow adequate representation of ADEPT models. 

We then provide a property-preserving reduction from 
these extended models to LTSs, to enable application of 
our LTS-based formal analysis algorithms. Finally, we 
briefly discuss the analyses we were able to perform on 
the autopilot model with our extended framework. 

Introduction 

Despite the fact that the complexity of automated systems 
constantly increases, it is important to be able to design in- 
terfaces that enable human operators to control the system 
in unambiguous ways. Our work is concerned with provid- 
ing automated formal analysis techniques for HMI systems. 
In particular, we have developed a formal framework for the 
design and analysis of such systems, and have applied it to 
a number of moderately sized case studies (Combefis et al. 
2011a). 

Human operators typically interact with a system based 
on a conceptual model that they carry in their mind, or that 
is provided through documentation. In this work, we use the 
term “mental model” to refer to such conceptual models, 
not to be confused with cognitive models that are also used 
in HMI research. Our analysis framework is built around a 
formally defined conformance relation called “full-control” 
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between an actual system and a mental model according to 
which it is operated. Systems are well-designed if they can 
be described by relatively simple, full-control, mental mod- 
els for their human operators. For this reason, our framework 
supports automated generation of minimal full-control men- 
tal models for HMI systems, where both the system and the 
mental model are described as labelled transition systems 
(LTS). 

However, in applying our framework to system models 
developed by HMI collaborators at NASA Ames, we re- 
alised that LTSs are conceptually far from the way in which 
HMI designers typically think about their systems. LTSs are 
state machines that contain no information on their states 
except for the transitions and behaviours that are enabled 
starting from these states. Contrary to that, HMI designers 
think of their systems in terms of a set of observable and 
unobservable state variables; different combinations of val- 
uations of these variables constitute the set of possible states 
of the system, and transitions describe how user commands 
or environmental events change the state of the system. 

In this paper, we describe our work on extending LTSs 
with state information, thus enabling a direct mapping of 
ADEPT models into extended LTSs. We also discuss how 
we extend our framework for HMI analysis to deal with such 
models. We applied the extended framework to an ADEPT 
autopilot model; this has been a challenging case study since 
our techniques could not scale to the size of the full model. 
Due to lack of space, we only summarise some of the results 
obtained from our analysis. 

Related Work 

Campos et al. (2011; 2008) propose a framework for 
analysing HMI using model-checking. They define a set of 
generic usability properties (Campos and Harrison 2008), 
such as the possibility to undo an action. These properties 
can be expressed in a modal logic called MAL and checked 
with a model checker on the system. This approach targets 
specific, and precise usability properties whereas our ap- 
proach uses a more generic definition of good systems, and 
is complementary to their analysis. 

Thimbleby et al. (2007; 2010) use graphs to represent 
models. They study usability properties of the system by 
analysing structural properties of graphs like the maximum 
degree and the value of centrality measures. In their ap- 


proach, there is no distinction among actions and there is 
little focus on the dynamic aspects of the interaction. 

Curzon et al. (2007) use a framework based on defin- 
ing systems with modal logic. Properties of the model are 
checked using a theorem prover. Similarly to Campos et al., 
properties of interest are more targeted to a specific usability 
property while our approach is more generic. 

Navarre et al. (2001; 2003) also developed a framework 
to analyse interactive systems. Their focus is on the com- 
bination of user task models and system models. We focus 
mainly on the system model although we have also explored 
an approach for checking whether a user task is supported 
by a system model (Combefis 2009). 

Bolton et al. (2008; 2011; 2010) developed a framework 
used to help predicting human errors and system failures. 
Models of the system are analysed against erroneous human 
behaviour models. The analysis is based on task-analytic 
models and taxonomies of erroneous human behaviour. All 
those models are merged into one model which is then anal- 
ysed by a model checker to prove that some safety properties 
are satisfied. 

Bredereke et al. (2002; 2005) formalised mode confusions 
and developed a framework to reduce them. The formalisa- 
tion is based on a specification/implementation refinement 
relation. Their work is targeted on mode confusion while 
the work presented here is targeted to more general control- 
lability issues. 

Model-based testing has been used to analyse sys- 
tems modelled as Input-Output Labelled Transition Sys- 
tems (IOTS) (Tretmans 2008). The IO conformance relation 
(IOCO) is defined to describe the relationship between im- 
plementations and specifications. The IOCO relation states 
that the outputs produced by an implementation must, at any 
point, be a subset of the corresponding outputs in the spec- 
ification. This is triggered by the fact that IOCO is used in 
the context of testing implementations. Outputs are similar 
to observations in our context. The full-control property de- 
fined in our work needs to consider commands (inputs) in 
addition to observations. 

Modelling and Analysing HMI systems 

This section provides a brief overview of our previously 
developed analysis framework for labelled transition sys- 
tems (Combefis et al. 2011a). In our framework, system 
and mental models are modelled with enriched LTSs called 
HMI-LTSs, which are essentially graphs whose edges are 
labelled with actions. The difference with classical LTSs is 
that three kinds of actions are defined; such distinction mat- 
ters when concerned with controllability properties of sys- 
tems (Heymann and Degani 2007; Javaux 2002): 

1. Commands are actions triggered by the user on the sys- 
tem; they are also referred to as inputs to the system; 

2. Observations are actions autonomously triggered by the 
system but that the user can observe; they are also referred 
to as outputs from the system; 

3. Internal actions are neither controlled nor observed by the 
user; they correspond to internal behaviour of the system 
that is completely hidden to the user. 


Formally, HMI-LTSs are tuples (S, O'. O’ , so, —>) where 
S is the set of states, C c and C° are the sets of com- 
mands and observations respectively, s 0 is the initial state 
and — >C S x ( C c U£°U {r}) x S is the transition relation. 
Internal actions cannot be distinguished by the user and are 
thus denoted with the same symbol r, called the internal ac- 
tion. The set of observable actions comprises commands and 
observations and is denoted C = £ c U C°. 

When a transition exists between states s and s' with ac- 
tion a, i.e., ( s , a , s') 6 — >, we say that the action a is en- 
abled in state s and we write s -—y s' . An HMI-LTS is de- 
terministic if it has no internal transitions and its transition 
relation is a function from (S x ( C c U C°)) to S. In other 
words, if s ——$■ s i and s S 2 , then si = S 2 ■ The set 
of commands that are enabled in a state s, denoted r c (s), 
contains all the commands a such that there exists a state 

s' with s > s' . The set of enabled observations T°(s) is 

defined similarly. 

Internal actions can occur between observable actions. A 
weak transition s ==> s' corresponds to s - T a - T > s', 
where r* means zero, one or more occurrences of r. The set 
of commands that are possible in a state s, denoted A c (s), 
corresponds to commands a such that there exists a state s' 
with s ==> s'. The set of possible observations, denoted 
A°(s), is defined similarly. A trace a = (cci, . . . , a n ) is a 
sequence of observable actions in C that can be executed on 
the system, that is, such that sq ■ ai > Si . . . s n - 1 > s n . 

The set of traces of an LTS A4 is denoted TV (Ad). 

Full-control property 

In our work, mental models are represented in terms of de- 
terministic HMI-LTSs. They capture a simplified model of 
the system, as perceived by a human operator. We then de- 
fine the full-control property to capture the fact that an op- 
erator’s mental model carries enough information to enable 
proper control of the system. Full-control requires that, at 
any time during the interaction between the user and the sys- 
tem: 

• the user knows exactly what are the possible commands 
on the system: the set of possible commands is the same 
on both the system and mental models; 

• and the user is aware of at least the observations that can 
occur: the set of possible observations according to the 
mental model contains the ones possible on the system 
model. 

Formally, a mental model H = {Shi O', C°, sq h , — >h) 
allows full-control of a given system S = ( Ss,C c ,C° , 
s o s > ~^s) if and °nly if: 

Vtr € C* such that so s ==>■ ss and sq h sh ■ 

A c (s s ) = A c (s h ) and A°(s s ) C A°(s H ) (1) 

The existence of a full-control mental model for a given 
system model is guaranteed if the system is full-control 
deterministic, or fc-deterministic. This property, defined 
in (Combefis and Pecheur 2009), requires that the non- 
determinism in a system does not interfere with its control- 
lability; in other words, a system can be non-deterministic, 


so long as it is still possible to construct a full-control mental 
model for it. 


Interaction Analysis 

Based on the full-control property, we proposed a frame- 
work and methodology to analyse systems from an HMI 
standpoint (Combefis et al. 2011a). Two algorithms were 
developed in (Combefis and Pecheur 2009; Combefis et al. 
201 lb), which are focused on the automatic generation of a 
minimal full-control mental model for a given system. The 
first is based on the definition of a bisimulation-based rela- 
tion between the states of the system, stating which of them 
can be merged together because they can be handled simi- 
larly from the standpoint of the operator. The second uses 
a learning algorithm which iteratively builds mental model 
guesses. The algorithm relies on a teacher to answer whether 
proposed execution sequences must, may or cannot be part 
of the mental model. The teacher uses the system model to 
answer such queries. 

As the main input is a model of the system, the analy- 
sis can be performed and used in different steps of the HMI 
design process. In the evaluation phase, the analysis gives 
feedback regarding whether the model of the system is con- 
trollable by an operator. If it is not controllable, the analysis 
provides an example of a problematic interaction. The analy- 
sis can also be used at the end of the design process, once the 
system has been validated, in order to build artefacts such as 
user manuals, trainings, etc. 

ADEPT 

ADEPT ( Automatic Design and Evaluation Prototyping 
Toolset ) (Feary 2010) is a Java-based tool developed at 
NASA Ames, which supports designers in the early proto- 
typing phases of the design of automation interfaces. The 
tool also offers a set of basic analyses that can be performed 
on the model under development. An ADEPT model is com- 
posed of two elements: a set of logic tables, coupled with 
an interactive user interface (UI). The logic tables describe 
the dynamics of the system as state changes in reaction to 
user actions or to environmental events. For example. Fig- 
ure 1 shows a screenshot of the autopilot model opened in 
ADEPT. The left part of the window shows one of the logic 
tables and the right part shows the user interface. 

The UI is composed of a set of components that are en- 
coded as Java objects representing graphical widgets. The 
logic tables can refer to the elements of the UI and to the 
other components through their Java instance variables, and 
interact with them through their methods, using Java syntax. 
In particular, UI events are seen as boolean variables that are 
set to true when the event occurs. 

Behind the scene, an ADEPT model is compiled into a 
Java program that can be executed in order to directly try 
the encoded behaviour with the user interface. That tool is 
meant to be used as a rapid prototyping tool. The models can 
then be tested and simulated by the designers, but can also 
be analysed by systematic and rigorous techniques. Possi- 
ble analyses include validity checks on the structure of logic 
tables, for example. Our aim is to extend the analysis capa- 
bilities of ADEPT with our framework, which requires the 



Figure 1 : The autopilot model opened in ADEPT, with one 
logic table in the left part of the window and the user inter- 
face on the right part. 


translation of ADEPT tables into the models that our frame- 
work can handle. 

Figure 2 shows one of the logic tables of the au- 
topilot model. The table example illustrates the way it 
can interact with elements of the UI. Each light grey 
line of the table corresponds to a variable of the sys- 
tem. The variables can be related to a component of the 
UI (such as pfdAirspeedTargetTape.currentValue), or they 
can be state variables of the model (such as indicatedAir- 
Speed) or they can relate to the internal logic of the system 
(airspeedSystemTable.outputState). The latter kind of vari- 
ables can be seen as a description of the mode of a particular 
component of the system (the airspeed part in this example). 
For example, the two first lines of the output part of the logic 
table example mean that the value of the currentValue field 
of the pfdAirspeedTargetTape component of the UI is up- 
dated with the value of the indicatedAirspeed state variable. 
Moreover, each column of an ADEPT table corresponds to 
a transition scenario. From any state of the system that sat- 
isfies the condition described by the input part of the table, 
the system can move to the state of the system that results 
in applying the update instructions described by the output 
part of the table. 


State Event Models 

As already mentioned, HMI-LTSs are event-based, meaning 
that their states contain no information except for the be- 
haviour in terms of events enabled in these states. On the 
other hand, as discussed above, ADEPT models combine 
state with transition information. Systems are composed of 
a set of variables, each system state corresponding to an as- 
signment of values to the variables. Some variables are ob- 
servable through the user interface, and tables describe the 
possible transitions from each state as a result of reacting 
to user commands or environmental events. A direct trans- 
lation of ADEPT models into HMI-LTSs proved challeng- 
ing, and for this reason we decided to extend HMI-LTSs 
by adding information on the states in the style of Kripke 
structures (Clarke Jr., Grumberg, and Peled 1999). In order 
to represent observable information on states, HVSs enrich 
HMI-LTSs with a set of state-values and with a mapping 
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Figure 2: An example of a logic table: the airspeed feedback 
table of the autopilot model contains the logic related to the 
update of the UI for the airspeed part. 

function associating each state to one state-value. 

Definition 1 (HMI state- Valued System model (HVS)) 

A HMI state-valued system model (HVS) is a tuple 
(S, C c , C ° , so, — A C v ,0) where (S, C c , C° , so, — >) is an 
HMI-LTS, O’ is a finite set of state-values and O : S i— >• O 
is a state-value mapping function. The three sets O’, C° and 
O are disjoint. 

The set of state-values C v and function O describe, for 
each state, the observations that can be made by the opera- 
tor when the system is in that state. The difference between 
the state and transition related observations is in the inter- 
pretation according to a human-machine interaction point of 
view. The observations that can be made on the state may 
be ignored by the operator while interacting with the sys- 
tem. In contrary, observations occurring on a transition are 
output by the system and are expected to be seen by the op- 
erator for the interaction to proceed according to the chosen 
definition. Note that we do not model the possibility for the 
operator to get distracted and miss the observation. 

Mental models are similarly enriched to include state in- 
formation. Observations can be event-based (observations 
on transitions) or state-based (state-values on states). State- 
values are taken into account in the human model by action 
guards, that is, conditions on the state-value that must be 
verified in the current state of the system. In order to rep- 
resent mental models, HVMs are HMI-LTS s enriched with 
state-values on the transitions. Moreover, as already stated, 
mental models are considered deterministic and free of r- 
transitions in this work. 

Definition 2 (HMI state- Valued Mental model (HVM)) 

A HMI state- valued mental model (HVM) is a tuple 
(S, O’, C ° , So, — L C v ) where C v is a finite set of state- 
values, -> C S x O x C x S and (S, C v x C c , O x O’ , s 0 , ->) 
is a deterministic HMI-LTS without r-transition. The three 
sets O’, O’ and C v are disjoint. 


HVSs and HVMs do not handle state observation in the 
same way. That distinction is a result of the meaning of both 
models in terms of human-machine interaction. The opera- 
tor must always have the ability to make an observation on 
the machine, depending on its state. Concerning the mental 
model, the state-value is used to condition the actions that 
the operator may execute. In one given state, the operator 
may have several actions with guarded with different state- 
values. 

For an HVS and HVM that share the same alphabet of 
actions and state-observations, their interaction is defined as 
follows: 

Definition 3 (Interaction between an HVS and HVM) 

Given an HVS S = (Ss, O’, O, so s , — >s, O, O) and 
an HVM H = (Sh,0,0,sq h ,^h,0), the inter- 

action between S and FL, denoted S ||j H , is an LTS 
I = ( Si, O’ U C o ,S 0 j ,—. >/) where Si C (Ss x Sh), 
sqj = (so s , Sq h ) and — >i C Si x (C c U C° U {r}) x Si is 
defined so that: 

• (s Sl , s Hl ) -^4 ( Ss 2 , sh 2 ) if and only ifs Sl -4- Ss 2 and 

M a . , , 

s Hl > sh 2 with V = 0(ssj 

• and (s Sl ,s Hl ) -4- (ss 2 ,s Hl ) if and only if s Sl — 4 
Ss 2 - 

Intuitively, the operator can perform a visible action (com- 
mand or observation) if the state-value of the current state of 
the system agrees with the action guard that is present on the 
mental model. 

For enriched models, the full-control property is defined 
based on the above interaction model. The difference with 
the definition based on HMI-LTS is that possible commands 
and observations have to be considered in pair with the as- 
sociated state- value (from the source state for HVSs and on 
the action guard for HVMs). 

Definition 4 (Full-Control Property) For HVS S = ( Ss , 

C c ,C° lS0s ,^s,CfO) and HVM jj = (S Hi C c ,C°,s 0h , 
-^■h,£ v )> fi is said to allow full-control of S, which is de- 
noted HtcS, if and only if for all reachable ( Ss,sh ) £ 

5 11/ H: 

• ^4 c (ss) = A c (s h ); 

• and A 0 (sg) C A°(sh) 

where A c (s) = {(u, c) | 3s T > s' -4- s" A» = O(s') A 

c £ C c } for HVSs and A c (s) = {(u, c) | 3s - 9 ^° > s' A v |= 
g A c £ CAj for HVMs. The A°(s) set is defined similarly. 

Enriched models can be expanded into HMI-LTSs so that 
the full-control property is preserved. The motivation for 
such an expansion is to make it possible to perform the same 
reasoning and analyses that can be done on HMI-LTSs. The 
expansion operation transforms state-values into observation 
actions. 

The expansion of an HVS is based on the mapping shown 
on Figure 3. Every non-r transition s — ^4 t is expanded 
so that the state-value v is checked before the occurrence of 
the action, that is, a new state s v is added to the expanded 
model with the sequence of transitions s —^4 s v — 4 t. For 



r-transitions, no transformation occur, they are preserved in 
the expanded HMI-LTS. 
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Figure 3: Transition mapping for HVS to HMI-LTS trans- 
lation for non-r transitions. The transition from the original 
system model (on the left) induces two transitions in the ex- 
panded system model (on the right), where v = O(s). 

Definition 5 (Expansion of an HVS to an HMI-LTS) 

The expansion exp(S) of HVS S = (Ss, £ c , £°, So s , — >-s, 
C v ,0), is an HMI-LTS £ = (S E X C , 

C° E , s 0s , — > e) where C° E =£“U£" and: 

• S E = Ss U {s” | s £ Ss, v = O(s) and T(s) 7 ^ 0}; 

• —>e= {( s,r,t ) | (. s,r,t ) S -Ls} 

U {(s, v, s v ), ( s v , a, t) | (s, a, t) £ — >s and v = 0(s)}. 

By construction, the states of the expanded HMI-LTS can 
be partitioned into two sets: 

• Observation states are those from the original HVS and 
intuitively correspond to the fact that the operator must 
check the state-value before the occurrence of a visible 
action on the system. Those states can have outgoing r- 
transitions and at most one outgoing transition labelled 
with a state-value. An observation state s is characterised 
by |A°(s)| = 1, A°(s) C C v and A c {s) = 0. 

• Action states are the states added to the HVS. Those states 
have outgoing transitions with commands and observa- 
tions that correspond to those from the original HVS. 
They do not have any r-transitions. An action state s is 
characterised by A(s) C £. 

Transitions outgoing from an observation state lead to an 
action state, except for r-transitions that lead to another ob- 
servation state. And conversely, transitions outgoing from an 
action state always lead to an observation state. 

HVMs can also be expanded into HMI-LTSs, so as to 
make enriched traces explicit. The expansion is based on the 
intuition that the operator must always first check whether 
the action guard is satisfied before doing any visible action. 
Figure 4 shows the mapping between the transitions from 
the HVM and the corresponding expanded HMI-LTS. Ev- 
ery transition s > s' is expanded so that the state-value 
v is checked before performing the a action, that is, a new 
state s v is added to the expanded model with the sequence 
of transitions s s v — s'. 
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Figure 4: Transition mapping for HVM expansion. The tran- 
sition from the HVM (on the left) induces two transitions in 
the expanded HMI-LTS (on the right). 

Definition 6 (Expansion of an HVM to an HMI-LTS) 

The expansion exp(TL) of an HVM ft = (S#,£ c ,£°, 


sa a ,-> H ,C v ). is an HMI-LTSS = {S E , Cf C° El s 0h , ^ E ) 
where C° E = C° U C v and: 

• S E = S H ll{s v \ s £ S H , 0 , v, a , t) £ —>■#}; 

• -Le= {(s,v,s u )> ( s v ,a,t ) | (s,v,a,t) £ ->#}. 

Similarly to HVSs, two kinds of states are identifiable by 
construction: observation states and action states. The obser- 
vation states intuitively correspond to the check of the action 
guard by the user. They are characterised by T(s) C C and 
their outgoing transitions always lead to an action state. The 
action states correspond to those from the HVM. They are 
characterised by T(s) C C. Their outgoing transitions are 
labelled with commands and observations and always lead 
to an observation state. 

According to the following theorem, proven in (Combefis 
2013), it is possible to reduce the check that an HVM al- 
lows full control of an HVS, to the equivalent check that the 
expanded mental model allows full-control of the expanded 
system model. 

Theorem 7 Given an HVS S = (Ss,C c ,C°,So s ,^>-s, 
C v , O) and an HVM LL = (S’#, £ c , £°, sq h ,^h, £ v ): 

HicS exp( r H) fc exp{S) 

Experience with the Autopilot model 

The ADEPT autopilot partially models the behaviour of the 
autopilot of a Boeing 777 aircraft. The full autopilot ADEPT 
model has a total of 38 logic tables. Three major groups of 
tables can be identified in the model, namely one for the lat- 
eral aspect, one for the vertical aspect and finally one for the 
airspeed aspect. For each of these aspects, the logic tables 
are further partitioned into three groups: the action tables, 
the system tables and the feedback tables, successively exe- 
cuted in that order. Action tables determine actions from UI 
events, system tables update the state of the system accord- 
ing to the performed action, and feedback tables reflect the 
state of the system to UI elements. Our analyses focus on the 
system tables. 

Due to space limitations, we are not able to fully report on 
our experience with the autopilot case study. Details of the 
system and our analysis results can be found in (Combefis 
2013). However, we outline in this section some of the re- 
sults we obtained and observations we made. 

First of all, by extending our HMI models with state in- 
formation, we were able to automatically translate the au- 
topilot tables, which would have been very hard to perform 
reliably by hand, given the size of the system. Moreover, 
our techniques cannot scale to the full size of such a large 
and complex model, the main reason being related to the 
large number of system variables with large domains caus- 
ing a state explosion issue. Therefore, our analyses were per- 
formed on parts of the autopilot model, each analysis consid- 
ering subsets of the system tables. As is typical with formal 
techniques, we additionally had to abstract the infinite data 
domains involved in the models. 

Using the outputState as a mode indicator, we performed 
mode confusion analysis, and detected a potential mode con- 
fusion on the airspeedSystemTable. 


This was identified during the minimal model generation 
phase, where the generation algorithm produced an error 
trace witnessing the fact that the system model was not fc- 
deterministic. By analysing the error trace manually, we lo- 
calised the erroneous behaviour in the involved ADEPT ta- 
bles. 

One of the models that was analysed was an HVS with 
7680 states and 66242 transitions, among which 57545 are 
labelled with commands and 8697 are internal r-transitions. 
The obtained minimal mental model has 25 states and 180 
transitions. 

Finally, the semantics and translation algorithms that we 
have developed are only a first step towards effectively inte- 
grating our techniques with ADEPT. While we have worked 
on translating ADEPT models to HVSs, we still need to be 
able to directly relate the results of our analyses with the 
original ADEPT models. In the future, we therefore plan on 
working on a better integration of our analysis tools with 
ADEPT, better visualisation of the analysis results, and on 
increasing scalability of our analysis algorithms. 
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